Name the underlying native thread on all Apple platforms#130180
Name the underlying native thread on all Apple platforms#130180kotlarmilos with Copilot wants to merge 5 commits into
Conversation
Co-authored-by: kotlarmilos <11523312+kotlarmilos@users.noreply.github.com>
…fter release Co-authored-by: kotlarmilos <11523312+kotlarmilos@users.noreply.github.com>
|
@copilot drop comments |
Co-authored-by: kotlarmilos <11523312+kotlarmilos@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR updates CoreCLR’s Thread::GetExposedObject (the lazy creator for the managed System.Threading.Thread instance) to notify an attached debugger immediately after the exposed object is successfully created, so the debugger can refresh its view of that thread.
Changes:
- Track when
GetExposedObjectis the call that actually creates/storesm_ExposedObject. - After
GCPROTECT_END()(and thus after releasing the ThreadStore lock), fireg_pDebugInterface->NameChangeEvent(NULL, this)when the current thread created its own exposed object and a debugger is attached.
Show a summary per file
| File | Description |
|---|---|
| src/coreclr/vm/threads.cpp | Adds a debugger notification after lazy creation of the managed Thread object to prompt a refresh/re-query of thread info. |
Copilot's findings
- Files reviewed: 1/1 changed files
- Comments generated: 0
|
Tagging subscribers to this area: @JulieLeeMSFT, @VSadov |
|
The managed thread name can be only ever set via exposed thread object. How do we end up in a situation where thread has name, but it does not have the managed exposed object in the first place? |
You are right, the debugger only ever reads the name from the managed Thread object through My reasoning up to this point was that native-origin threads such as the main thread create the exposed object lazily on the first managed read of I will fix the thread name in native debugger in this PR only until we understand better the managed case. |
Extend the startup native-thread naming path from TARGET_OSX to TARGET_APPLE so iOS, tvOS and MacCatalyst also name the underlying native thread, where only the thread itself can set its own name. This affects the thread name shown by native debuggers and tools. Also drop the earlier managed-debugger NameChangeEvent notification, which did not address the managed "No Name" case. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| // On other platforms, when the underlying native thread is created, | ||
| // the thread name is set to the name of the managed thread by another thread. | ||
| // However, on OS X and NativeAOT (across all OSes), only the thread itself can set its name. | ||
| // However, on Apple platforms and NativeAOT (across all OSes), only the thread itself can set its name. | ||
| // Therefore, by this point the native thread is still unnamed as it has not started yet. |
| #if TARGET_APPLE || NATIVEAOT | ||
| // On other platforms, when the underlying native thread is created, | ||
| // the thread name is set to the name of the managed thread by another thread. | ||
| // However, on OS X and NativeAOT (across all OSes), only the thread itself can set its name. | ||
| // However, on Apple platforms and NativeAOT (across all OSes), only the thread itself can set its name. | ||
| // Therefore, by this point the native thread is still unnamed as it has not started yet. |
I think so. |
On startup, the managed thread name is copied to the underlying native thread only where the thread must name itself, and that path was guarded by
TARGET_OSX, so on iOS, tvOS and MacCatalyst the native thread kept its default name and native debuggers and tools never saw the managed thread name. This PR updates the guard toTARGET_APPLEso all Apple platforms name their native thread.Contributes to #130166